前言

在上一篇文章中，我們探討了 LLM 可觀測性平台的重要性。今天，我們將延伸這個主題，深入探討一個與其緊密相關且至關重要的領域：Prompt Management。

多數 LLM 可觀測性平台，如 Langfuse、Langsmith 等，都提供了強大的 Prompt 管理解決方案。這並非偶然，因為 Prompt 管理與模型的可觀測性、評估 (Evals) 功能有著密不可分的關係。當然，市面上也有獨立的 Prompt 管理工具，但今天我們將聚焦於整合性平台，探討它們如何將 Prompt 從簡單的字串提升為企業級的數位資產。

Prompt Management 的行前須知

首先，在我們開始了解 Prompt Management 之前，團隊可以根據自身的規模和成熟度，從以下幾點簡單的判斷合適的 Prompt 策略：

1. 初期 ：僅適用於快速實驗，能儘快迭代就迭代，驗證概念為主。
2. 成長期：將 Prompts 存放在 Git 的 JSON/YAML 檔案中，提供基本的版本控制。
3. 擴展期：採用如 Langfuse、Langsmith 等專用平台，實現完整的版本控制、協作、測試、部署和監控功能，將 Prompt 從程式碼中徹底解耦。

了解自己團隊中真正的需求，是否真的需要這些工具與複雜度，還是只是單純的為導入而導入，這也是我們不斷會學習到的課題。

當你在凝視深淵，深淵也在凝視著你。

為什麼我們需要 Prompt Management**？**

當一個 AI 應用從概念驗證 (POC) 走向正式生產環境時，將 Prompt 直接寫在程式碼中 (很 hardcoding) 的作法會迅速成為瓶頸。有效的 Prompt 管理變得至關重要，其核心價值在於：

• 職責解耦：讓 AI 工程師能專注於實踐複雜的 Agent 工作流，而將 Prompt 的設計與優化交給更理解業務邏輯的領域專家或 Prompt 工程師。
• 敏捷迭代：將 Prompt 與應用程式碼分離，使得修改和部署 Prompt 不再需要重新部署整個應用，大幅提升迭代速度。
• 跨團隊協作：提示工程 (Prompt Engineering) 是一門跨學科的藝術。產品經理、行銷專家，甚至法務人員，可能比軟體工程師更懂得如何撰寫有效的 Prompt。一個好的管理平台能建立清晰的工作流程，讓不同背景的團隊成員都能貢獻其專業知識。
• 確保品質與一致性：透過系統化的管理，確保 AI 模型的輸出能維持高品質、安全且風格一致。

接下來就讓我們從各種角度來拆解Prompt Management 的核心概念，我們將會理解在現今的 LLM 應用發展趨勢中， Prompt 已經不再只是程式碼的一部分，而是整個組織需要重點列管的重要資產 。

了解 Prompt 的可組合性：從結構到版本

在現代 AI 應用中，一個 Prompt 早已不是單一的靜態字串，而是一個可組合、可動態生成的「軟體元件」。它的複雜性與強大之處，正來自於其模組化的組合方式。要精通 Prompt 管理，我們必須先理解構成一個 Prompt 的三大核心要素：模板 (Template)、結構 (Structure) 與 版本 (Version)。

Prompt Template：動態與客製化的基礎

Prompt 模板是將靜態指令與動態資料結合的橋樑。與其將使用者問題寫死在程式碼中，我們使用帶有佔位符的模板，在執行時才將真實資料「注入」其中。這就像是一個填空題，讓我們的 Prompt 能夠應對千變萬化的使用者輸入。

核心價值：

• 邏輯與資料分離：將固定的指令（“你是一個客服，這是我們的退貨政策...”）與變動的資料（使用者的具體問題）徹底分開，讓程式碼更乾淨、更易維護。
• 一致性與可複用性：確保每一次與模型的互動都遵循相同的格式與指令，一個設計良好的模板可以被重複使用於成千上萬次不同的對話中。
• 安全性：透過模板化，可以更好地控制輸入的格式，降低 Prompt 注入攻擊的風險。

Prompt Structure：引導模型思考的藍圖

如果說模板是 Prompt 的「血肉」，那麼結構就是其「骨架」。一個高效的 Prompt 不會是雜亂無章的指令堆砌，而是一個經過精心設計、層次分明的引導藍圖。這個結構為模型提供了完成任務所需的所有上下文，確保它能準確、可靠地執行指令。

一個設計精良的 Prompt 結構通常包含以下幾個關鍵部分：

• 角色與目標 (Task Context)：
  • 目的：為模型設定一個清晰的身份（Persona）和目標。
  • 範例：「你是一位資深的旅遊規劃師，你的目標是為使用者打造一份經濟實惠且充滿驚喜的行程。」
• 語氣與風格 (Tone Context)：
  • 目的：控制模型的輸出風格，確保其符合品牌形象或應用場景。
  • 範例：「請使用友善、熱情且專業的語氣進行回覆。」
• 背景資料與文件 (Background & Documents)：
  • 目的：提供必要的外部知識，讓模型能基於事實而非幻覺來回答問題。這是 RAG (Retrieval-Augmented Generation) 應用的核心。
  • 範例：將使用者的歷史訂單、相關的 FAQ 文件或搜尋到的網頁內容放在這裡。
• 指令、規則與範例 (Instructions, Rules & Examples)：
  • 目的：給予模型具體、無歧義的操作步驟，並透過「少樣本 (Few-shot)」範例來展示期望的輸入與輸出格式。
  • 範例：「步驟一：分析問題。步驟二：總結需求。禁止回答與產品無關的問題。例如，如果使用者問『如何退貨』，你應該回答『...』。」
• 輸出格式化 (Output Formatting)：
  • 目的：強制模型以特定格式（如 JSON、Markdown 表格）回傳結果，以便後續的程式能穩定地解析和使用。
  • 範例：「請務必以 JSON 格式回傳，且必須包含 'status' 和 'response' 兩個鍵。」

Prompt Version**：迭代與優化的生命週期**

Prompt 不是一次性寫成的完美作品，它是一個需要不斷測試、調整和優化的「活資產」。業務需求會變更、模型會升級、使用者回饋會帶來新的價值，這一切都驅動著 Prompt 的持續演進。這就是版本控制至關重要的原因。

系統化的版本管理帶來了以下好處：

• 可追溯性與除錯：當線上發生問題時，我們可以立刻追溯到是哪個 Prompt 版本導致了異常輸出，並快速將其與前一個穩定版本進行比較，極大地縮短了除錯時間。
• 安全的實驗環境：團隊可以放心地在開發或預備環境中測試新的 Prompt 版本 (例如 v2-experimental)，而不會影響到正在為真實用戶提供服務的生產版本 (v1-stable)。
• 效能回歸測試：當 LLM 模型本身升級時（例如從 GPT-4 升級到 GPT-4o），我們可以利用版本控制來系統性地測試所有現有的 Prompt，確保其表現不會意外下降（即「迴歸」）。
• 輕鬆回滾：如果一個新上線的 Prompt 版本表現不如預期（例如，成本更高或準確率更低），管理員可以一鍵將生產環境回滾到上一個已知的穩定版本，保障服務品質。

中心化 Prompt 管理後台：協作與實驗的核心

當 Prompt 演變成包含模板、結構和版本控制的複雜資產後，將它們散落在程式碼、Slack 或文件中就成了一場災難。為了解決這個挑戰，一個中心化的 Prompt 管理後台應運而生。它不僅是一個儲存庫，更是一個跨職能團隊的協作中樞與實驗平台。

它的核心價值在於將 Prompt 從應用程式碼中徹底解耦 (Decoupling)。這意味著 Prompt 的修改、測試和部署可以獨立於軟體的發布週期。產品經理、領域專家或 Prompt 工程師現在可以在一個視覺化的介面中，安全地優化 Prompt，而無需撰寫一行程式碼或等待工程師重新部署服務。

這個後台通常提供兩大核心功能，以應對 AI 應用開發中最常見的挑戰：

Prompt Playground**：在混亂中尋找最佳組合**

在現實世界中，「最好的 LLM」並不存在，只存在「最適合當前任務的 LLM」。團隊需要基於成本、延遲、準確性及特定領域的知識，在眾多模型中做出權衡。Prompt Playground 正是為此而生的終極實驗場。

它解決了傳統開發流程中的一個巨大痛點：如果沒有 Playground，要比較 GPT-4o 和 Claude 3 Opus 對同一個 Prompt 的反應，工程師可能需要建立兩個獨立的測試分支，這既耗時又繁瑣。

核心價值：

• 即時橫向比較：如上圖所示，使用者可以在同一個介面中，輸入相同的變數，並排查看不同模型（甚至同一模型的不同版本）的輸出結果，優劣一目了然。
• 快速迭代與探索：非技術背景的團隊成員也能輕鬆調整 Prompt 的措辭、範例或參數（如溫度），並立即看到結果，大大加速了找到最佳 Prompt 的過程。
• 成本與效能分析：優秀的 Playground 還會顯示每次呼叫的 Token 消耗和延遲，幫助團隊在追求品質的同時，也能做出符合成本效益的決策。

版本控制 (Versioning)：像管理程式碼一樣管理 Prompt

專業的 Prompt 管理平台會自動為每一次變更建立版本紀錄，就像 Git 對程式碼所做的一樣。這條清晰的歷史軌跡是團隊協作與系統穩定性的基石。

核心價值：

• 完整的稽核軌跡：清楚記錄了「誰在什麼時間，出於什麼原因，做了什麼修改」，讓每一次變更都有據可查。
• 一鍵回滾：當新發布的 Prompt 版本 v3 導致線上輸出品質下降時，管理員可以立即將生產環境回滾至已知的穩定版本 v2，將損失降到最低。
• 精準的 A/B 測試：可以輕鬆部署兩個或多個 Prompt 版本，並根據真實用戶的數據來評估哪個版本的表現更好。

標籤 (Tagging)：從開發到生產的受控部署

僅有版本歷史是不夠的。我們還需要一個機制來管理哪個版本應該在哪個環境中使用。這就是「標籤」發揮作用的地方，它將軟體開發中成熟的環境管理 (Environment Management) 概念引入到 Prompt 管理中。

我們可以建立如 development、staging 和 production 等標籤，並將它們指向特定的 Prompt 版本。

• development 標籤可能指向最新的、尚在實驗中的 v4-dev 版本。
• staging 標籤可能指向已經過內部測試，準備上線的 v3 版本。
• production 標籤則穩定地指向正在為所有用戶提供服務的 v2 版本。

這個流程確保了任何變更都必須經過層層驗證，才能被「晉升」到生產環境，極大地提升了穩定性。

SDK：連接後台與應用程式的橋樑

最後，這一切是如何在應用程式中生效的呢？答案是透過平台提供的 SDK。應用程式的程式碼不再包含巨大的 Prompt 字串，而是變成一個簡單的 API 呼叫。

如上圖的程式碼所示，開發者只需告訴 SDK：「請給我名為 movie-critic 的 Prompt，並且是我標記為 production 的那個版本」。

這種模式實現了終極的靈活性：Prompt 團隊可以在後台將 production 標籤從 v2 更新到 v3，線上應用程式無需重新部署，就會在下一次請求時自動拉取並使用最新的 Prompt。這真正實現了 Prompt 的執行時更新 (Runtime Update)。

終極目標：將 Prompt 管理融入 GitOps

雖然一個功能強大的 UI 讓 Prompt 的編輯變得前所未有的簡單，但它也帶來了一個新的問題：我們如何將這個「UI 驅動的變更」與企業級軟體開發中「以 Git 為中心」的『單一事實來源 (Single Source of Truth)』原則相協調？

答案就是 GitOps！將 Prompt 管理與 Git 工作流整合，是實現 Prompt 生命週期完全自動化、可追溯性與可靠性的終極形態。它完美地橋接了兩個世界：Prompt 工程師喜愛的視覺化介面與開發維運團隊信賴的自動化 CI/CD 管線。

實現方式一：原生整合 (以 Langfuse 為例)

最無縫的整合方式是平台原生提供。以 Langfuse 為例，它內建了與 GitHub Actions 的深度整合，將手動操作轉化為自動化流程。

這個流程的運作方式如下：

1. 觸發點：團隊成員在 Langfuse 的 UI 介面中編輯了一個 Prompt，並點擊了「儲存」或「發布」。
2. 事件派發：Langfuse 系統會自動向預先設定好的 GitHub Repo 發送一個 repository_dispatch 事件。這就像是 Langfuse 在對 GitHub 說：「嘿，我這裡有個 Prompt 更新了，該你接手了！」
3. 啟動工作流：這個事件會自動觸發 GitHub Actions 中定義好的一個 CI/CD 工作流，開始執行一系列預設的自動化操作。

實現方式二：通用 Webhook (以 LangSmith 為例)

並非所有平台都提供如此深度的原生整合。更常見且靈活的作法是提供 Webhook 功能。Webhook 就像是一個通用的通知系統：當 Prompt 被更新時，平台會向你指定的 URL 發送一個包含變更資訊的 HTTP POST 請求。

這種方式給予了團隊極大的自由度：

• 你可以建立一個簡單的 Serverless 函數 (如 AWS Lambda, Google Cloud Functions) 來接收這個 Webhook。
• 收到通知後，你可以自由觸發任何後續操作，無論是呼叫 Jenkins、啟動 GitLab CI，還是觸發 GitHub Actions。

自動化 CI/CD 工作流的威力

無論是透過原生整合還是 Webhook，其最終目標都是啟動一個自動化的工作流。這個工作流遠不止是簡單的備份，它是一個保障品質與穩定性的安全閥。一個典型的 Prompt GitOps 工作流會包含以下步驟：

• 1. 自動化評估 (Automated Evaluation)：
  • 這是最關鍵的一步。工作流會自動取出新的 Prompt 版本，用一組預先定義好的「黃金測試集」(Golden Dataset) 來進行評估。
  • 評估指標可能包括：輸出格式是否為有效的 JSON？語氣是否符合要求？是否包含有害內容？Token 成本是否在預算內？與上一個版本相比，回答的準確性是提升還是下降了？
  • 只有當所有評估指標都通過時，工作流才會進入下一步。
• 2. 提交至 Git Repo (Commit to Git)：
  • 一旦測試通過，工作流會將新的 Prompt 內容（通常是 JSON 或 YAML 格式）自動提交到一個專門的 Git Repo 中。
  • 這一步確保了 Git 真正成為了『單一事實來源』。即使 Langfuse 的資料庫發生問題，你依然擁有所有 Prompt 版本的完整歷史紀錄。
• 3. 晉升環境標籤 (Promote Environment Tag)：
  • 工作流會自動更新 Prompt 管理平台上的標籤。例如，將 staging 標籤從舊版本 v2 指向剛剛通過測試的新版本 v3。這一步實現了 Prompt 的自動化「晉升」。
• 4. 觸發下游部署 (Trigger Downstream Deployments)：
  • 在某些情況下，Prompt 的變更可能需要應用程式碼的微小調整。工作流可以在成功晉升 Prompt 後，觸發另一個部署流程，發布對應的應用程式版本。

透過這套流程，我們將 Prompt 的生命週期管理從手動操作，提升到了企業級 CI/CD 的高度，其核心價值在於：

• 極致的自動化：消除人為錯誤，確保每一次部署都經過相同的嚴格測試。
• 無可辯駁的可靠性：自動化評估是防止有問題的 Prompt 進入生產環境的最強防線。
• 真正的單一事實來源：無論變更來自何處，最終的權威記錄都存放在 Git 中，實現了完美的追蹤與稽核。

大規模 Prompt Management 架構的考量

當我們將 Prompt 從程式碼中解耦，並透過一個中心化後台在執行時動態載入時，我們無形中創造了一個新的關鍵基礎設施。get_prompt 這個看似簡單的函數呼叫，從一個內部操作，演變為一個必須在生產環境中 24/7 可靠運行的網路服務。

這種架構轉變雖然帶來了巨大的靈活性，但也引入了一個嚴峻的挑戰：單點故障 (Single Point of Failure, SPOF)。如果 Prompt 管理系統變慢或停機，所有依賴它的 AI 應用程式將會立刻降級甚至完全癱瘓。因此，其後端架構必須滿足企業級的嚴苛標準。

這主要體現在三大核心挑戰上：

1. 高可用性 (High Availability)：系統必須具備極高的可靠性。任何停機時間都可能直接轉化為業務損失和用戶信任的流失。
2. 低延遲 (Low Latency)：get_prompt 的響應時間是每次 AI 互動總延遲的一部分。對於即時聊天或使用者體驗要求高的應用，即使是 100 毫秒的額外延遲也是無法接受的。
3. 高擴展性 (High Scalability)：當應用程式的使用者從一千人增長到一百萬人時，Prompt 服務的請求量也會同步飆升。架構必須能夠平滑地擴展以應對這種讀取密集型 (read-heavy) 的負載。

Langfuse 架構從 v2 到 v3 的演進

為了具體理解如何應對這些挑戰，讓我們深入分析 Langfuse 這個真實世界的例子。其架構從 v2 到 v3 的演進，完美地展示了一套 Prompt 管理系統如何從一個簡單的應用，成長為一個為大規模生產環境設計的健壯服務。

Langfuse v2：一個好的開始

Langfuse v2 的架構相對簡單：一個 Web Server 直接與一個 Postgres 資料庫溝通。

• 優點：易於開發、部署和維護。
• 瓶頸：在這種架構下，同一個 Postgres 資料庫既要處理大量的寫入操作（例如，記錄 LLM 的追蹤日誌），又要處理至關重要的讀取操作 (get_prompt)。當負載增加時，讀寫之間的資源競爭會導致 get_prompt 的延遲飆升，甚至可能因為資料庫過載而導致服務不可用，直接觸及了我們前面提到的延遲和擴展性的痛點。

Langfuse v3：為規模化而生的架構

意識到 v2 架構的局限性，Langfuse v3 進行了徹底的重新設計，其核心思想是關注點分離 (Separation of Concerns)，並為每個任務選擇最合適的工具。

• 引入 Redis 作為快取層：
  • 解決的問題：低延遲。
  • 運作方式：絕大多數的 get_prompt 請求會直接命中速度極快的 Redis 記憶體快取，而無需訪問較慢的後端資料庫。這確保了即使在巨大流量下，也能維持毫秒級的響應時間。
• 將讀取負載轉移到 Clickhouse：
  • 解決的問題：高擴展性與讀寫分離。
  • 運作方式：Langfuse 團隊意識到，獲取 Prompt 是一個典型的分析型、讀取密集的場景。因此，他們將這部分負載從專為交易型寫入設計的 Postgres，轉移到了專為海量數據快速讀取而優化的 Clickhouse 分析型資料庫。這徹底解決了讀寫競爭的問題，讓系統的吞吐量提升了一個數量級。
• 使用非同步 Worker：
  • 解決的問題：高可用性與系統響應能力。
  • 運作方式：將耗時的任務（如數據處理、日誌聚合）交給後台的非同步工作者處理，確保了主 Web Server 能夠保持輕量和高響應性，專注於處理即時的 API 請求。

透過這次架構升級，Langfuse 確保了 get_prompt 不再僅僅是一個功能，而是一個能夠支撐企業級 AI 應用的高可用、低延遲、高擴展性的核心服務。這個演進路徑對於任何希望將 AI 應用推向大規模生產的團隊來說，都具有深刻的借鑒意義。

Prompt 管理的核心原則與最佳實踐

回顧全文，將 Prompt 視為軟體開發生命週期的一部分，並引入類似 DevOps 的管理思維是成功擴展 AI 應用的關鍵。

從最初的混亂到最終的自動化流程，我們可以將一個成功的 Prompt 管理策略總結為以下幾個核心實踐。無論你選擇哪種工具，這些原則都將是通往成功的基石：

總結

隨著 AI 技術的飛速發展，Prompt 管理本身也在不斷進化，但這絕對不會是終點。未來，我們將看到更多利用 AI 自動優化 Prompt 的技術、針對 Prompt 注入攻擊的防禦手段，以及將 Prompt 管理與 CI/CD 管線更深度整合的創新實踐。將 Prompt 視為核心資產並加以妥善管理，將是所有成功 AI 應用的共同特徵。

References：

• https://langfuse.com/docs/prompt-management/overview
• https://docs.langchain.com/langsmith/prompt-engineering-concepts
• https://arize.com/docs/phoenix/prompt-engineering/concepts-prompts/prompts-concepts
• https://langfuse.com/blog/2024-12-langfuse-v3-infrastructure-evolution
• https://www.youtube.com/watch?v=8gTpgWru0Wg&list=PLf2m23nhTg1P5BsOHUOXyQz5RhfUSSVUi&index=1
• https://langfuse.com/docs/prompt-management/data-model
• https://arize.com/blog/prompt-learning-using-english-feedback-to-optimize-llm-systems/
• https://arize.com/blog/prompt-optimization-few-shot-prompting/